System and Method for Management of End User Computing Devices

ABSTRACT

A system and method is provided for the repair of operating system and application binary files and configuration data files at pre-operating system boot stage by comparing attributes of the files against a reference collection of such files stored on a server during each reboot or restart cycle while creating and restoring a collection of dynamic operating system binary files, configuration data files, file system structures and hardware system attributes unique to the configuration and use of the system on a server for subsequent pre-operating system repair operations.

CROSS REFERENCE TO RELATED APPLICATION

This application is a divisional application of co-pending U.S. patentapplication Ser. No. 10/290,240, filed Nov. 8, 2002, which claims thebenefit of U.S. Provisional Patent Application No. 60/331,192, filedNov. 9, 2001, both of which are incorporated by reference in theirentirety.

FIELD OF INVENTION

The present invention relates generally to systems and methods forproviding improved maintenance of computing systems. More particularly,the present invention relates to a system and method for providingimproved support and maintenance functions for end user computersystems.

BACKGROUND OF INVENTION

There are many tasks associated with managing a computer system. Suchtasks are required regardless of whether the computer system is anetwork of interconnected computers or a standalone computing system.Moreover, such tasks are required regardless of whether the computersystem includes equipment associated with remote and wirelessapplications.

One of these tasks relates to repairs of lost, damaged, or modifiedfiles, which render the computer system in a state where it cannotachieve its purpose in the context of the organization for which itexists. Such repairs often require the application of additionalsoftware, a knowledgeable technician, or even a group of technicians towork on the computer system. Repairs and maintenance consume valuableresources, including time, office resources, and human resources.

Alternative means for implementing repairs on computer systems, otherthan allocating technicians to the repair system, are often difficult toimplement, costly and potentially destructive to user data. Knownsupport and maintenance systems do not take into account changes to thecomputer system since its initial installation, its last period ofmaintenance, or changes to the system due to user, network, orperipheral initiated events.

Moreover, known software-based techniques for providing maintenance andrepairs typically require the target operating system to be functioning,which may be impossible if, as is often the case, the target operatingsystem is not functioning. In that situation, effecting repairs is verydifficult. Also, if the target operating system was running when aproblem occurred, files or data that needed to be repaired or updatedmight be locked, thus preventing maintenance. Another problem occurswhen the target operating system requires the use of non-optimizedmethods of network and storage access. This would slow activitiesrelated to deployment, update, and repair.

Accordingly, there is a need for a product to address both existing andemerging challenges in the management of end user computing devices.More specifically, there is a need for a system and method that restores(self-repairs) a computer system in the event of software failure due touser error, introduction of virus, system crash, or other problem. Theproduct should provide dramatic improvements for IT managers in terms ofcost reduction and user satisfaction while allowing them to apply theirefforts to more strategic and value-added initiatives by minimizingsupport calls and stabilizing their environment.

SUMMARY OF THE INVENTION

The present invention provides a method that satisfies a need of manycomputer users to better manage their computing devices. A preferredembodiment of the invention is a method for managing end user computingdevices. The method includes the following steps. First, a referencecollection of files associated with an operating system of a client iscreated. Preferably, the reference collection of files includesapplication binary files and configuration data files. Second, thereference collection is stored on a server, which is in communicationwith the client. The reference collection may also be stored on a hiddencache of the client. Third, attributes of application binary files andconfiguration data files of the client are compared against thereference collection during a reboot cycle of the client. Fourth, storedinstructions and files are ensured that they are capable of bringing theoperating system of the client to a usable state.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic diagram showing an exemplary architecture of anembodiment of the invention.

FIG. 2 is a schematic diagram showing an exemplary architecture ofclient-resident components of a system according to an embodiment of theinvention.

FIGS. 3A and 3B are collectively a schematic diagram showing examples ofthe capture of plug-and-play or hardware usage-pattern data using ahardware differential data countdown according to one embodiment of theinvention.

DETAILED DESCRIPTION OF THE INVENTION

Preferred embodiments of the invention is described below andschematically illustrated in the drawings. The description and drawingsare only for the purpose of illustration and as an aid to understandingthe invention. The description and drawings provided herein are notintended as a definition of the limits of the invention.

The preferred embodiment of the invention is an intelligent desktopmanagement solution, which is hereinafter referred to as “IDMS”). IDMSprovides a simple, transparent, and non-disruptive approach to usersupport.

IDMS delivers the following functions. First, IDMS recovers clientcomputers which have crashed. The client computers could crash due to anumber of reasons. For example, client computers could crash due tooperating system failure, application crashes, or crashes due to virusesor hacking. To recover his system, all a user needs to do is reboot hiscomputer. IDMS takes care of the repair and does it automatically andtransparently. No other action on the part of the user or from technicalsupport is required.

Second, IDMS works on networked computers (clients) that becomestandalone. For example, IDMS can work on notebook computers that aretaken on business trips. When a networked client computer is notconnected to a network and a problem is experienced, the auto-repairprocess does not require any type of network connection or access to anyother system. All that is required is a reboot of the computer. IDMSprovides the only known method that can resolve problems of this typewithout any involvement of the support line, technical supportpersonnel, or the end-user (other than initiating a reboot on thedevice).

Third, IDMS helps quarantine and minimize damage from viruses and hackerattacks. IDMS provides an easy way for users to rapidly recover fromviruses or damage from hacker attacks while enabling the organization toprevent broader impacts to shared computing resources. Common virusesthat attack operating system and application files can be easilycontained by simply asking users to reboot and immediately run theiranti-virus software and/or delete the offending e-mail/file.

Fourth, IDMS provides advanced deployment of applications, operatingsystems and update capabilities over the network, from the server to theclient. For example, a migration from Windows 2000 to Windows XP can beexecuted in fewer than 10 minutes. It is noted that IDMS deployssoftware in a way that it does not diminish the system's workings in thecontext of the organization, structure, or operating environment inwhich it exists. There are a number of existing products that can deployan operating, but do so in a manner that ignores context and theramifications of future maintenance and self-repairing. An architectureof IDMS enables network administrators to add incremental items tosoftware images previously built and deployed to clients. Thiseliminates the need to create an entirely new image for each combinationor permutation of the device's context (as is required by manycompetitor's deployment solutions).

IDMS accomplishes all of this by creating and maintaining a “persistentimage” on the client device. The concept of a persistent image meansthat the computer is able to automatically repair itself and return to astable operating environment after something disrupts, deletes ordamages key files that control the essential functions that the userdepends upon. A disruption often occurs due to user error. Sometimes itcan result from addition of new software that causes conflicts with thepre-existing software. And, increasingly, the disruption can come frommalicious actions by computer hackers and the effects of computerviruses. Having a persistent image means that a PC—or any other computerdevice—can be restored to normal operation immediately by simplypowering off and back on. Every time the device boots, IDMS executes apre-boot sequence that automatically repairs any damage that hasoccurred since the previous boot.

While IDMS is focused on providing auto-repair functionality as its corepurpose, it also offers broader management capabilities. For instance,because it uses its own method for system imaging and softwaredeployment, it eliminates the need for other products.

Moreover, IDMS offers important assistance in the security and disasterrecovery arenas. IDMS ensures that no permanent harm is done when keysystem operations are temporarily disrupted, whether by naturaldisaster, hardware failure, software crashes, viruses, or hackerattacks.

IDMS has been successfully adapted to work on desktop and portable PCsrunning Windows 9x, NT4.0, Windows 2000, Windows XP, and Linux. Inaddition, IDMS can be adapted to work on a Windows CE version to supportthe Compaq iPAQ and other CE-based systems, including CE-based embeddedsystems.

IDMS provides two client product types. The first client product type isa Single O/S, which allows a user to manage one operating system or oneimage per client. The second client product type is a Multi-O/S, whichallows up to four different operating systems or images per client. TheMulti-O/S allows the user to switch from one operating system to anotherwith a simple reboot. It also allows multiple images of the same O/S onone client where more than one person might use a single machine (e.g.,schools or other training environments). This version is also a hugetime-saver in a QA environment where technicians are testing softwareagainst several operating systems and require a stable image for eachtest.

During pre-boot, IDMS detects and self-repairs problem files or registrysettings. This means that, by simply rebooting the PC, an end-user canautomatically resolve O/S or application file corruption, therebyeliminating calls to the helpdesk. To implement this capability, an ITadministrator creates a “perfect image” of the 0/S and application filesto be automatically self-repaired and supported by IDMS. This image isthen compressed with a reversible algorithm and a MD5 hash is generatedfor the entire compressed image. The image and associated checksum arethen stored on both a server and in a local cache (hidden partition) onthe local client disk drive. Each time the client device is rebooted,the automatic self-repair of files is done by comparing the hard diskcontent with the content of an image stored on the local cache partition(or the server), and then restoring only the files that need to berestored. Most importantly, the “perfect image” and the unique profileof the machine type automatically adapt over time to conditions unknownor unforeseen by the IT administrator, creating not only a self-repaircapability, but a self-managing feature as well.

This is accomplished by comparing each file of the O/S and applicationsto the files in the “perfect image”. If there is a corrupted file, amissing file or an entire set of missing files, those damaged or missingfiles are simply replaced as the system is loading. The result is thatwhen systems become unstable, the users need only to reboot their PCs.This ensures that every time the PC is rebooted it has a healthy 0/S andapplication set available so that the user can be productive. Often, auser won't even realize there was a problem because his system alwaysreboots to a healthy environment.

IDMS has the following feature/function capabilities:

-   -   Enable Server-Based Image Multicasting by using mTFTP to push        software images from the IDMS server to the workstation,        reducing the demand on network bandwidth and eliminating visits        to the desktop or other user device;    -   Compress image files by 50% on average to further reduce network        traffic;    -   Streamline the deployment of operating systems, application        updates, and user settings to desktop and mobile workforces;    -   Allow IT managers to remotely image any Windows workstation. The        central console can also be used to quickly deploy whole        application packages or specific PC changes such as registry        changes or desktop settings;    -   Accelerate migration to Windows 2000 and Windows XP™;    -   Enable customized deployment of software or operating systems to        a specific department or groups;    -   Allow three levels of O/S and application management and        security;    -   Support multiple partitions, with up to four Operating Systems        on the same unit;    -   Self-repair the most critical files—including NTDetect, NTLDR,        and NT Registry settings, or any other corrupted system or        application file;    -   Maintain user data and custom settings after an automatic        self-repair operation;    -   Fully Support laptop users with intelligent capabilities while        they are disconnected from the network; and    -   Take full advantage of Intel's pre-boot execution environment        (PXE) technology to further automate the deployment of 0/S and        application images.    -   A preferred IDMS server of has the following minimum        requirements:    -   Pentium III (minimum) processor, 5 12 MB RAM (If more than 250        concurrent users, scale as appropriate);    -   Disk Storage requirements are based on the number of base images        and packages;    -   Network Operating System Windows NT, Windows 2000 Server, or        Linux; and    -   DHCP Server installed locally or on another server available on        the network remotely.    -   A preferred IDMS client has the following minimum requirements:    -   Personal computer 300 MHz, 6 GB hard disk, 64 MB RAM;    -   PXE-enabled network adapter or PXE boot diskette; and    -   A DHCP server installed on the network is required.    -   In addition, IDMS is adapted to offer the following core        features:    -   The IDMS management platform includes a virtual machine (VM) for        executing compiled programs (i.e. scripts), a graphical        interface to interact with the user, utilization of low-level        hard disk access for        imaging/restoring/auto-repairing/customizing operating systems        and finally a network interface through the PXE boot-rom;    -   Management tasks can be performed either interactively (with GUI        wizards, or by entering commands at the interactive prompt), or        in scripts containing command line statements;    -   Powerful but easy-to-use programming language (e.g., Rembo-C,        the syntax of which is similar to JavaScript and PHP);    -   Virtual machine (VM) executing Rembo-C compiled epodes (RBX),        e.g., the Virtual Machine is multi-threaded, and supports        structured exception handlers;    -   On-the-fly compiler to interactively compile Rembo-C statements        into VM opcodes;    -   Hard-disk buffering engine (like smartdrive); and    -   Utilizes the capability of performing file operation on        un-partitioned space on the local hard disk to store local        copies of files and IDMS data sets transferred from the server,        in order to speed-up subsequent accesses to the same file (This        feature dramatically improves performance when restoring the        same operating system disk image several times on the same        computer. Leaving some un partitions space on the hard disk for        the local cache partition is strongly recommended when IDMS is        used to restore an operating system every day, or at every boot        (OS failure prevention by preemptive OS restoration)).    -   Preferably, IDMS provides the following graphical interface        features:    -   Hypertext-based graphical user interface, with a visual        programming language-like event handlers for executing IDMS        statements when an action is triggered by the user;    -   16 bits display (32768 colors) or 256 colors video mode, all        standard VESA modes supported;    -   Pointing devices, including, but not limited to Serial, USB,        PS/2 mice supported (including wheel mice);    -   All the graphical interface objects are mapped to abstract        variables/objects or Document Object Model Constructs or        interface element object hierarchy, so that any object on the        screen can be modified interactively or in scripts; and    -   256 colors PCX image format support. A variety of graphics        formats can be used to create display elements, including PCX,        JPEG, PNG or future formats as available.    -   Preferably, IDMS offers the following file system features:    -   File-based support for FAT12, FAT16, BIGDOS, FAT32, EXT2FS,        LINUXSWAP, NTFS (NT4.0) and NTFS (Win2K);    -   NTFS limitations (1 DMS cannot decrypt files encrypted with        Win2K encryption keys, and cannot access NTFS compressed files);    -   On the fly partitioning Rembo-C functions;    -   File-based functions (to read, write, copy, delete, rename, move        files and directories);    -   Auto-repairing;    -   Guaranteed application availability on every desktop that        proactively corrects file and configuration related issues        before the end user knows there's a problem; and    -   Repair of deleted files, overwritten DLL's, incorrect file        versions, corrupted registries and more (Auto-repairing runs        during pre-boot so even critical boot files are protected.        Unlike similar auto-repairing technologies, IDMS replaces the        necessary files, without overwriting the entire application or        user data).    -   Preferably, IDMS offers the following OS deployment:    -   Utilization of Image Creation and Image restoration of operating        system disk images (An image corresponds to a collection of        files, with no requirement on the source used to build the        image, i.e., a user can create an image containing 50% of NTFS        files and 50% of FAT16 files);    -   Compressed partition images (Images can be browsed directly from        the IDMS client);    -   Support for partition image size of 100 GB;    -   Utilization of Virtual images (A Virtual lineage is an exact        copy of a file system's structure, but without copying the files        content. A user can remove a directory in a virtual image        without actually removing the directory on the disk. Virtual        images are useful for pruning unwanted files/directories on        image creation, and for merging images together on restoration        (e.g. to restore a base image+a software image));    -   Unlimited differential imaging (create a differential of images,        and restore combinations of base+differential images);    -   File based cloning, allowing auto-repairing operations        (Auto-repairing is done by comparing the hard-disk content with        the content of an image stored on the server (or the local cache        partition), and restore only the files that need to be restored.        In auto-repairing mode, a NT workstation can be restored to a        safe state in less than 10 seconds); and    -   Unlimited post-configuration (The low-level file system access        implemented in IDMS, combined with the Rembo-C programming        language makes OS configuration very easy).

Preferably, IDMS offers the following OS Specific features:

-   -   Utilization of Low-level access to NT registry files (Windows        NT4.0 & 2000) from IDMS (The Windows Registry is handled as a        file system, thus making possible to create basic images and        differential images of the registry as for hard disk images.        This is a very useful feature for software deployment);    -   Compatible with Microsoft's System Preparation Tool (SysPrep);    -   SD (NT's system identifier) re-generation functions; and    -   Linux kernel boot module (like LILO), including support for        large initial ram disk.

Preferably, IDMS offers the following network features:

-   -   Proprietary IP implementation, designed for performance, with        UDP based proprietary protocols;    -   NETfs, unicast file transfer protocol used to transfer files        from and to the IDMS server;    -   Utilization of MCAST, multicast file transfer protocol (server        to clients), using adaptive timeouts and windows (about 5-10        times faster than MTFTP, a standard protocol for multicast file        transfers) or any type of broadcast protocol;    -   The MCAST protocol does not require any kind of synchronization        between the clients—soft synchronization (Therefore, no manual        intervention is required to rollout hundreds of PCs if MCAST is        combined with Wake-On Lan (power-on computers remotely));    -   The FAST protocol, unicast window-based protocol, used to send        files to the server;    -   Communications between the server and the client are encrypted        using strong encryption standards;    -   All protocols are failure-prone: they will reconnect to a server        even if the server was restarted;    -   Backup servers are supported: the clients can switch to the        backup server in the middle of a transfer if the primary 1 DMS        server has failed;    -   Access to TCP services through a special tunneling mechanism;    -   SMTP support (send emails with IDMS); and    -   Complete (read and write) database access, using ODBC.

Preferably, IDMS offers the following miscellaneous features:

-   -   Remote Console: IDMS client display can be controlled from a        remote location with an IDMS Remote Console application        (Communications between the IDMS client and the Remote Console        are compressed and encrypted);    -   Authentication: Windows NT, Unix (passwd), NIS/NIS+, and RADIUS        (for any other server) authentication protocols are supported by        IDMS to authenticate a user (e.g. to grant access to the        computer based on the identity of the user);    -   Hardware detection: IDMS can detect ISA PnP and PCI devices, and        provides full access to DM1 (SMBIOS) and CMOS through Rembo-C        functions; and    -   CD-Rom and Floppy mode: IDMS can be started from a floppy disk        or a CD-Rom in places where PXE remote-boot is not available        (The CD-Rom image can be customized to contain specific        partition images or IDMS scripts).

Preferably, during pre-boot, IDMS automatically restores the client'smachine based on one of the following selectable lock down modes:

-   -   Mode 1—Full Lock-Down—Restore base image and incremental(s) but        do not preserve user's desktop settings, data in My Documents,        or any applications that are not installed with IDMS. Note:        During the auto-heal process data located in private folders        (i.e. c:\work) remains intact.    -   Mode 2—No Lock-Down—Restore base image and incremental(s) but        preserve user's desktop settings, data in My Documents, and any        applications that are not installed with TDMS.    -   Mode 3—Semi Lock-Down—Restore base image and incremental(s) but        preserve user's desktop settings, data in My Documents and do        not preserve any applications that are not installed with IDMS.

FIG. 1 is a schematic diagram showing an exemplary architecture of anembodiment of IDMS. System 100 of the invention includes server-residentcomponents 102 and client-resident components 104 (see FIG. 2). As shownin FIG. 1, server-resident components 102, which resides at server 400,include client profile data 110, client usage pattern data 120, andreference collection data 130. Client-resident components 104 residingat client 500, which is one of clients 101, 103, 105, 107, 109, and 111,are illustrated in FIG. 2 and is discussed below.

Server 400 stores or indexes the storage of client profile data 110.Server 400 also includes client usage pattern data 120, which is coupledto each client profile data 110.

Client usage pattern data 120 is also coupled to reference collectiondata 130. Via network 200, server 400 is in communication with one ormore target machines 101, 103, 105, 107, 109, and nth target machine 111(collectively client 500). Client 500 receives from or transmits toserver 400 instructions and usage-pattern data. The instructions andusage-pattern data are exchanged according to the instructions given toclient-resident components 104.

Client-resident components 104 include code in the native instructionset of server 400, which is loaded into a client machine's memory. Thememory can be a physical memory, a paged memory on a secondary storage,or scripts interpreted into machine instructions by anotherclient-resident component. Although only one server is depicted in FIG.1, two or more servers may represent server 400.

FIG. 2 is a schematic diagram showing an exemplary architecture ofclient-resident components 104 of system 100. Examples of the sequenceof client-resident components 104 are as follows: Upon each reboot orrestart of client 500, a client script is transmitted from server 400via network 200. The client script becomes run client script process 207as a pre-boot program, where client profile data 110 is loaded fromserver 400 to direct the decisions and actions of run client scriptprocess 207.

Run client script process 207 initiates the capture of usage patterninformation process 208, which references client profile data store 210.Run client script process 207 preferably captures usage-pattern datafrom a target machine's secondary storage device 211, or alternatively,other storage media.

An exemplary embodiment for capturing usage-pattern data is illustratedin FIG. 3A and FIG. 3B. Usage data related to heterogeneous hardware iscaptured in process 208 using a hardware differential detection method,in which the client script 207 replaces the target operating systemsshell with a program. The program then functions as a timer to run for aset period of time. When the timer expires, the program triggers areboot or restart of the target operating system. In one embodiment, atimed interval allows the target operating system to run plug-and-playand hardware/software configuration routines for the individual targetcomputer. After a reboot or restart, these changes are detected andstored as part of the target machine's unique profile on server 400and/or a server surrogate (not shown) (such as a hidden cache ofexecutable instructions and data on a target machine's hard drive).

Another example of capturing usage-pattern data related to heterogeneoushardware in process 208 uses a hardware differential detection method.Here, client script 207 replaces the target operating system shell witha program that runs after process 216. Client script 207 can beconfigured to function as the timeout. Alternatively, the program can dothe following: (1) scan the operating system's process table and memorystructures to detect, for example, the signatures associated with arunning plug-and-play or hardware configuration process; (2) store thechanges associated with the plug-and-play and hardware configurationprocess in a local or networked repository; and (3) reboot or restartthe system once the process is complete.

The following is a representation of the code to substitute thecountdown timer as the operating system shell, according to oneembodiment of client script 207. /****** invention/reboot * NAME *reboot.c -- Program to insert reboot or restart code into WindowsNT/2000 * * INPUTS * None * BUGS * None ****** */ /****v* reboot /msgs *NAME * msgs * DESCRIPTION * Displays what is being done on the userdesktop * NOTES * None ****** */ str msgs; /****f* reboot/message *NAME * message * DESCRIPTION * Displays the messages on the userdesktop * SYNOPSIS * message(str msg) * INPUTS * msg - a string whichcontains what is being done * RETURN VALUE * None ****** */ voidmessage(str msg){ // Output a message to the user printf(“%s”,msg); }/****f* reboot/ForceReboot * NAME * ForceReboot or restart *DESCRIPTION * Makes Computer reboot or restart again if it is w2k or winnt writes shutdown.exe into registry * SYNOPSIS * ForceReboot (void) *INPUTS * None * RETURN VALUE * None ****** */ void ForceReboot (void) {if(TestFile(”c:/WINNT”)) { Copy(”server//global/plugins/shutdown.exe”,“c: /”); if(TestFile(”c://WINNT/system32/config/SOFTWARE”)) { OpenHive(“reg”, “c:/WINNT/system32/config/SOFTWARE”); str msgs = “CreatingUnicode File of shutdown.exe”; message (msgs); WriteUniToReg(“_reg/Microsoft/Windows NT/CurrentVersion/Winlogon/Shell.unicode”,“c:\\shutdown.exe /R /T:60 \“Completing invention Operations\” /L”);CloseHive (“_reg”); } else { //Halt on failure and issue a messageCriticalError(”Cannot open or modify the registry”); for(;;) { ) } }else if(TestFile (“c:/WINDOWS”)) {if(TestFile(“server//utilities/shutdown.exe”)){ Log(”\nCopyingshutdown.exe to the Win9x workstation.\n”); Copy (”server//utilities/shutdown.exe”, “c:/”); } else { CriticalError(”\nCannot findshutdown.exe file...Contact your system administrator! \n”); for(;;) { }} } } /****f* reboot/ResetReboot * NAME * ResetReboot * DESCRIPTION *Removes shutdown.exe from registry registry * SYNOPSIS * ResetReboot(void) * INPUTS * None * RETURN VALUE * None ****** */ void ResetReboot(void) { if(TestFile(”c:/WINNT”)) { if(TestFile(”c:/shutdown.exe”)) {Delete(”c:/shutdown.exe”); if(TestFile(”c:/WINNT/system32/config/SOFTWARE”)) { OpenHive(”_reg”, “C:/WINNT/system32/config/SOFTWARE”); WriteuniToReg ( “reg://reg/Microsoft/Windows NT/Current Version/Winlogon/Shell.unicode”,“Explorer.exe”); CloseHive (“_reg”); } } } elseif(TestFile(”c:/WINDOWS”)) { Log(”\nCleaning up all of IDMS files inWin9x \n”); if (TestFile (“c: /autoexec.bat”)) { Delete(”c:/autoexec.bat”); } if(TestFile(”c:/invention.bat”)) { Delete (”c:/invention.bat”); } if(TestFile(”c:/shutdown.exe”)) { Delete (“c:/shutdown.exe”); } Touch(”c:/autoexec.bat”,””); } } / *******/

Another example of the means for capturing usage-pattern data is byimplementing the following pseudo-code [p-code] algorithm in process208:

-   -   If the first time flag is TRUE, record the count of directories        in the user profile by performing steps 1-4 below, then reboot        or restart.    -   Step 1 Let Integer 1=0 (I is a generic counter variable);    -   Step 2 Loop While the function to get the next directory does        not return a value equivalent to the no more directories flag,        incrementing I by 1 each iteration through the loop.    -   Step 3 Output I to the profile store for the client.    -   Step 4 Store the initial user profiles directory structure and        configuration data to the server.    -   Reboot or restart    -   If the first time flag is FALSE, probe the target machine's user        profile archive to detect if a new user has logged into the same        machine and a new profile has been added.    -   Step 1 Let Count=f(x) where x is the retrieved value of the last        count of directories    -   Step 2 Let Integer I=0    -   Step 3 Loop While the function to get the next directory does        not return a value equivalent to the no more directories flag,        incrementing I by 1 each iteration through the loop.    -   Step 4 If Count is greater than 1, re-archive the entire set of        directories that store user profile information.

The following is a representation of the code used to implement a ruleto detect new users of a system in process 208: /****y*selfheal/user_count * NAME * user_count * DESCRIPTION * a counter whichis used to determine how many users are there in Documents and SettingsFolder * NOTES * if a change in this count is detected, the registrywill be set for recapture for mode 1 only ****** */ int user_count;[CODE ABRIDGED HERE] /* If this is the first time after initialdeployment, record the baseline count of user directories */if(TestFile(”c:/Docurnents and Settings”)) { dir =GetDirlnfo(”c:/Documents and Settings”); int new_user_count = sizeof(dir); WriteKeyValue (new_user_count, “user_count”, “host”); }DelKeyValue(”reboot”, “host”); [CODE ABRIDGED HERE] /* Compare thedirectory count each time to see if the recapture of data is necessary*/ if(os==”winnt”) { if(TestFile(”c:/Documents and Settings”)){ CObjectdir = GetDirlnfo(”c:/Documents and Settings”); int new_user_count =sizeof (dir); if (user_count < new_user_count) { recapture = true;WriteKeyValue (new_user_count, “user_count”, “host”); } }

Another method for capturing usage-pattern data related to heterogeneoushardware in process 208 can be embodied in a hardware differentialdetection method where the client script 207 replaces the targetoperating system shell with a program. This program runs concurrentlyand continuously with the target operating system, after process 216.The program can actually scan the operating system's process table andmemory structures to detect the signatures associated with a runningplug-and-play or hardware configuration process. If changes aredetected, the program can store the changes associated with theplug-and-play and hardware configuration process in a local or networkedrepository. An example of such repositories includes the operatingsystem vendor's database of configuration data. Once storage operationsare complete, the program can trigger a reboot or restart orre-initialization of the system.

In another embodiment, usage-pattern data can be captured (to ensurethat the system will be restored in a usable state consistent with itsactual uses) when client script 207 replaces or extends the targetoperating system's shell to capture and restore the operating system'snative emergency recovery data and stores this data in a local ornetworked repository.

In another embodiment, client script 207 replaces or extends the targetoperating system's shell or environment to include executableinstructions. The instructions enable the capture and analysis inprocess 208 of, for example, a human interface device (e.g., keyboard,handwriting recognition device, voice-recognition device, a moue oranother pointing device) and video information. Then client script 207can monitor, for example, user actions. In addition, client script 207can capture signature data files that indicate the tasks and activitiesoccurring on the system. The analysis can include detection of useractivities and, preferably, automatically schedule the installation oftools to make user tasks more efficient.

In another embodiment, run client script process 207 can control process208. The control can be done through a filter configuration file ordatabase, indicating data or structures to be added, removed, or omittedfrom control during the usage-pattern data capture process 208.

Preferably, the usage-pattern data is passed from capture usage patterninformation process 208 to parse stored usage-pattern informationprocess 209, which analyzes, sorts and packages usage-pattern data forstorage and/or sets flags or passes the data through a network of rulesto generate a list of actions.

In one embodiment, parse stored usage-pattern information process 209passes parsed usage-pattern data to store usage-pattern data process213. For example, the size and configuration of the secondary storagedevice is stored upon the initial deployment of the target system, andthen subsequently compared at each reboot or restart to detect a harddrive reconfiguration or malfunction. Parse usage pattern information209 preferably includes functions that compare information from thetarget machine against previous trend information and against rules todistinguish data indicating significant events or changes to the targetoperating system.

Preferably, store usage-pattern data process 213 stores the parsedusage-pattern data in the usage-pattern data repository store 212. Storeusage-pattern data process 213 also initiates repair target machineprocess 214.

Repair target machine process 214 reads and applies reference data fromreference collection data store 130 (FIG. 1) to the target machine'ssecondary storage device 211, rendering the target machine's secondarystorage device 211 to a known clean state without usage-pattern data.

Preferably, repair target machine process 214 then initiates reapplyusage pattern information process 215. Reapply usage pattern informationprocess 215 recalls usage pattern data for the target machine from theusage-pattern data repository store 212, then applies the usage patternto the target machine's secondary storage device 211, thus rendering thetarget machine's secondary storage device 211 to a state where allreference data and usage-pattern data on the target machine's secondarystorage media 211 are ensured to be in a usable state which correspondsto the target machine's actual uses.

A specific example of how script 207 can control process 215 by readingclient profile data 210 related to the use of configuration data thatcontrols the repair or restoration applications through the use of atimeout function is described below. First, a hash is computed from thenumber of seconds since the Unix epoch (Jan. 1, 1970). The hashrepresents specific second or tick when an application is to be disabledand removed from the healing or repair function in process 215. Duringsubsequent reboot or restarts or maintenance cycles, the hash iscompared to the system time and triggered actions are taken. Thespecific actions taken may depend selection of modes and methods torestore usage-pattern data.

Examples of defined modes in the preferred embodiment can be definedaccording to this code comment section: /****v* selfheal/mode * NAME *preconfigured * DESCRIPTION * mode that determines how is a machine tobe restored * mode = 1 - backup DAS and Registry only if there is a newsoftware detected (lockdown) * mode = 2 - backup DAS and Registry everyreboot or restart * mode = 3 - backup DAS every reboot or restart butregistry only if there is a new software detected * NOTES * This valueis read in from the file * DAS is an acronym for Documents and Settings****** */

Process 215 includes a selection of restoration modes for usage-patterndata. Such modes include a mode where all usage-pattern data is omittedand process 216 is activated without restoring usage-pattern data. Inanother mode, some usage-pattern data is reapplied and other data isomitted. In another mode, all usage-pattern data is reapplied duringprocess 215, the mode being set by reading client profile data 210.

Another embodiment of process 215 includes a method of statisticallysampling a selection of usage-pattern data as compared against targetmachine's secondary storage device 211 to ascertain a confidenceinterval (set by client profile 210) that the target machine's secondarystorage device 211 is in a state consistent with its actual uses. Thisoccurs without performing a one-to-one check of all tuples containingusage-pattern data checkpoints.

Another embodiment of process 215 includes a method of recording thetime/date stamp of several passes of control to process 216. If greaterthan n control passes occur within a set time interval (both n and theinterval provided by client profile 210), a signal is sent to the server100 indicating abnormal operation or user action.

If all repair or maintenance activities are complete, reapply clientinformation process 215 initiates a boot to the target machine's mainoperating system process 216, terminating all control and influence ofthe system from the target machine. In this way the target machine isrendered in a usable state that corresponds to its actual dynamic uses.

One embodiment of the invention is a method for the automated repair ofstatic operating system, application binary files, and configurationdata files at pre-operating system boot stage. The method includes thefollowing steps. First, attributes of the files against a referencecollection of such files accessible on a server are compared. Thereference collection can be stored on the server in a hard drive or adata schema. The comparison can be performed during at least one rebootor restart cycle. Second, a collection of dynamic operating systembinary files, configuration data files, file system structures, andhardware system attributes unique to the configuration and use of thesystem on the server are created and restored for subsequentpre-operating system repair operations. This ensures the system's storedinstructions and flies are capable of bringing the system to a usablestate which corresponds to its normal (i.e., actual) uses.

Another embodiment of the invention provides a system that executes themethod described above. The system includes an automatic client processcomponent. The client process component is loaded dynamically from aserver. This client process can be dependent or independent on thetarget operating system. The client process can be read from a networkor from a local server emulation. The client process component isexecutable on one or more of the set of client computer systems. Theclient process component includes a process or set of processes fordetermining the state of the machine via execution script data from thesystem server component. The client process script also compares thestate of the client against the known good state of the referencecollection, detecting and storing usage pattern information data andstructures and the merging of the known good state and the usage patterninformation to render the client capable of bringing the system to thedesired state.

In another embodiment, a system of the invention includes a componentthat provides a graphical user interface for use by the user to createthe ideal reference collection of data. The component also monitors theclient processes' automated actions and provides the user withconfigurable options to set the behavior of the system.

In another embodiment of the invention, the graphical user interface isreplaced with a text interface. Alternatively, the graphical userinterface may interact with the user through the use of natural languageor speech processing or via changes in the physiological state of theuser.

In another embodiment, a system of the invention includes a parsercomponent. The parser component parse ASCII format, Unicode or encodedor raw Binary data structures representing captured reference collectioninformation or usage pattern information stored as user profiles,filesystem folders or directories, text configuration files,configuration databases or registry data. Parsing activities includepacking and unpacking data, compressing or decompressing data,decomposing data into smaller units, composing larger units of data,comparing the meaning, parameters or magnitude of the data, evaluatingconditional relations between the data, aggregating data, or separatingdata. Parsing prepares the data for interpretation.

In another embodiment, a system of the invention includes a repositoryof the reference collection and usage pattern information as archives offiles, filesystem structures, text configuration files, configurationdatabases or registry data.

In another embodiments, the invention provides methods for modifying thebehavior of the system. For example, configuration data specific tosystem behavior can be modified.

Another embodiment of the invention provides a system that operates aDOS-compatible client system with one or more computers running either anon-DOS or DOS-based operating system or a system configured to receiveboot instructions from sources including but not limited to, removablemedia, fixed media, virtual media, network sources or affixed in anyother way by any other device.

In another embodiment, the present invention provides a system having acentral processing unit and random access memory. The system includes acomputer-usable medium having computer-readable code means embodied inthe medium for software for the automated repair of static operatingsystem and application binary files and configuration data files atpre-operating system boot or re-initialization stage. The centralprocessing unit and the random access memory are used to compareattributes of the files against a reference collection. The referencecollection includes such files stored on a server during each reboot orrestart cycle while creating and restoring a collection of dynamicoperating system binary files, configuration data files, file systemstructures and hardware system attributes unique to the configurationand use of the system. The files and attributes are stored on a serverfor subsequent pre-operating system repair or maintenance, operationsensuring the system's stored instructions and files are capable ofbringing the system to a usable state which corresponds to its actualdynamic uses.

An embodiment of the invention includes means for causing a computer toestablish communication to the server process and managing the creation,manipulation, storage and restoration of the collection of dynamicoperating system binary files, configuration data files, file systemstructures and hardware system attributes unique to the configurationand use of the system on a server for subsequent pre-operating systemrepair operations ensuring the system's stored instructions and filesare capable of bringing the system to a usable state which correspondsto its actual dynamic uses.

Another embodiment of the invention includes a computer-readable programcode as a means for causing a computer to modify server and systemconfiguration data to control the collection of dynamic operating systembinary files, configuration data files, file system structures andhardware system attributes unique to the configuration and use of thesystem on a server for subsequent pre-operating system repair operationsensuring the system's stored instructions and files are capable ofbringing the system to a usable state which corresponds to its actualdynamic uses.

The foregoing disclosure of the preferred embodiments of the presentinvention has been presented for purposes of illustration anddescription. It is not intended to be exhaustive or to limit theinvention to the precise forms disclosed. Many variations andmodifications of the embodiments described herein will be apparent toone of ordinary skill in the art in light of the above disclosure. Thescope of the invention is to be defined only by the claims appendedhereto, and by their equivalents.

Further, in describing representative embodiments of the presentinvention, the specification may have presented the method and/orprocess of the present invention as a particular sequence of steps.However, to the extent that the method or process does not rely on theparticular order of steps set forth herein, the method or process shouldnot be limited to the particular sequence of steps described. As one ofordinary skill in the art would appreciate, other sequences of steps maybe possible. Therefore, the particular order of the steps set forth inthe specification should not be construed as limitations on the claims.In addition, the claims directed to the method and/or process of thepresent invention should not be limited to the performance of theirsteps in the order written, and one skilled in the art can readilyappreciate that the sequences may be varied and still remain within thespirit and scope of the present invention.

1. A method for repairing a client having a damaged usage collection offiles, the damaged usage collection of files comprising operating systemfiles, application binary files, and configuration data files, at apre-operating system boot stage of the client, comprising: generating arepaired usage collection of files based on a dynamic referencecollection of files that was generated during a previous boot stage,wherein the dynamic reference collection of files accounts for actualdynamic uses of the operating system corresponding to the previous bootstage; repairing the damaged usage collection of files based on therepaired usage collection of files; whereby the repaired usagecollection of files restores the operating system to an actual dynamicuse of the operating system corresponding to the damaged usagecollection of files before damage occurred.
 2. The method of claim 1,wherein generating the repaired usage collection of files based on adynamic reference collection of files comprises using the dynamicreference collection of files as the repaired usage collection of files.3. The method of claim 1, wherein generating a repaired usage collectionof files further comprises comparing a reference collection of filesstored on a server against the dynamic reference collection of files,wherein the static reference collection of files corresponds to a stateof the client before actual dynamic uses of the operating system.
 4. Themethod of claim 3, wherein the reference collection of files is storedon one or both of a hidden cache of the client and a server incommunication with the client.
 5. A computer readable medium storingcomputer executable instructions for repairing a client having a damagedusage collection of files, the damaged usage collection of filescomprising operating system files, application binary files, andconfiguration data files, at a pre-operating system boot stage of theclient, the instructions operable when executed to: generate a repairedusage collection of files based on a dynamic reference collection offiles that was generated during a previous boot stage, wherein thedynamic reference collection of files accounts for actual dynamic usesof the operating system corresponding to the previous boot stage; repairthe damaged usage collection of files based on the repaired usagecollection of files; whereby the repaired usage collection of filesrestores the operating system to an actual dynamic use of the operatingsystem corresponding to the damaged usage collection of files beforedamage occurred.
 6. The computer readable medium of claim 5, furtheroperable use the dynamic reference collection of files as the repairedusage collection of files to generate the repaired usage collection offiles based on a dynamic reference collection of files.
 7. The computerreadable medium of claim 5, further operable to compare a referencecollection of files stored on a server against the dynamic referencecollection of files, wherein the static reference collection of filescorresponds to a state of the client before actual dynamic uses of theoperating system to generate a repaired usage collection of filesfurther comprises.
 8. The computer readable medium of claim 7, whereinthe reference collection of files is stored on one or both of a hiddencache of the client and a server in communication with the client.
 9. Asystem for repairing a client having a damaged usage collection offiles, the damaged usage collection of files comprising operating systemfiles, application binary files, and configuration data files, at apre-operating system boot stage of the client, the system comprising oneor more processing devices collectively operable to: generate a repairedusage collection of files based on a dynamic reference collection offiles that was generated during a previous boot stage, wherein thedynamic reference collection of files accounts for actual dynamic usesof the operating system corresponding to the previous boot stage; repairthe damaged usage collection of files based on the repaired usagecollection of files; whereby the repaired usage collection of filesrestores the operating system to an actual dynamic use of the operatingsystem corresponding to the damaged usage collection of files beforedamage occurred.
 10. The system of claim 9, further operable use thedynamic reference collection of files as the repaired usage collectionof files to generate the repaired usage collection of files based on adynamic reference collection of files.
 11. The system of claim 9,further operable to compare a reference collection of files stored on aserver against the dynamic reference collection of files, wherein thestatic reference collection of files corresponds to a state of theclient before actual dynamic uses of the operating system to generate arepaired usage collection of files further comprises.
 12. The system ofclaim 11, wherein the reference collection of files is stored on one orboth of a hidden cache of the client and a server in communication withthe client.